IRIX 6.2 Development Libraries

home *** CD-ROM | disk | FTP | other *** search

/ IRIX 6.2 Development Libraries / SGI IRIX 6.2 Development Libraries.iso / relnotes / gl_dev / ch7.z / ch7

Wrap

Text File | 1997-09-04 | 12.0 KB | 397 lines

- 1 - 6. _P_b_u_f_f_e_r_s__o_n__I_m_p_a_c_t The OpenGL Pbuffer extension is now supported on all impact configurations: Max Impact, High Impact, and Solid Impact. These release notes describe the Impact Pbuffer implementation in detail. This will be of use primarily to developers of opengl applications that use pbuffers. 6.1 _P_b_u_f_f_e_r__E_x_t_e_n_s_i_o_n_s Note that you will have to use the FBConfig extension to create pbuffers. Also, if you want to copy between pbuffers and windows, you will need to use the MakeCurrentRead extension. This release includes all three extensions: Pbuffers, MakeCurrentRead, and FBConfig. 6.2 _P_b_u_f_f_e_r__S_i_z_e_s Each pbuffer allocated consumes a set of bitplanes with the same geometry as the entire screen. So, if you run the monitor at 1280x1024, allocating a single buffer will actually consume 1280x1024 of offscreen framebuffer memory. It is impossible to create a pbuffer larger than the screen size. You can create one smaller, but the remaining screen memory will be wasted and cannot be allocated. In some Impact configurations, there are actually multiple sets of bitplanes available to pbuffers (pbuffer banks), so it is in some cases (e.g. max impact) it is possible to allocate more than one pbuffer at a time. See the section below called "Recommended pbuffer and window combinations." 6.3 _P_b_u_f_f_e_r__f_o_r_m_a_t_s This release supports the following pbuffer formats: All X visuals (except overlays) support pbuffers. This includes double buffered, and stereo quad-buffered visuals, and visuals with depth and stencil planes. All appear to work fine, and allow copies from pbuffers to windows, and windows to pbuffers. Note that the context used to do this copy must be created with the same fbconfig as the window (not the pbuffer). See the "glXMakeCurrent compatibility workaround" section below for details. - 2 - 6.4 _g_l_X_M_a_k_e_C_u_r_r_e_n_t__c_o_m_p_a_t_i_b_i_l_i_t_y__r_e_l_a_x_a_t_i_o_n In this release, glXMakeCurrent's strict compatibility requirements have been relaxed for pbuffers (but not for windows). Any context that meets certain very minimal requirements can be used to render into a pbuffer, or copy from a pbuffer. The requirements are simply that the window and context must have the same renderType; in other words, they must both be color index, or rgba. There are no requirements that the color depths of the context match those of the pbuffer, or anything of the sort. Note that windows still have strict similarity requirements. Contexts and windows bound together with glXMakeCurrent must have been created from the same visual. 6.5 _g_l_X_M_a_k_e_C_u_r_r_e_n_t__c_o_m_p_a_t_i_b_i_l_i_t_y__w_o_r_k_a_r_o_u_n_d In order to copy between pbuffers and windows, you will need to use the glXMakeCurrentReadSGIX extension. This is all very straightforward if the window, pbuffer, and context you are using were all created with the same FBConfigID (using glXCreateContextWithConfigSGIX). If they weren't created from the same fbconfigid, things get more complicated. A problem arises since there is a bug in the X server which requires that windows (but not pbuffers) and contexts be created from the exact same visual (or fbconfig). (This does not follow the spec since the fbconfig spec specifies that windows should work with any "compatible" context if the context was created from an fbconfig.) You must make sure that the window and context were always created with the EXACT SAME fbconfig or visual id. So, to copy from a single buffered pbuffer to a double buffered window, you must: +o create an sb pbuffer +o create a db window +o create a db context This will allow glXMakeCurrentReadSGIX to work correctly around this bug. Note that the above example would not work if the context were created single-buffered. This is due to the fact that makecurrent between the sb context and db - 3 - window would fail since the window and context were not created with reference to the exact same visual (or fbconfig). Note that the db context in the example above may be used with makecurrent(pbuffer), makecurrent(window), and makecurrentread(window, pbuffer), or makecurrentread(pbuffer, window) even though the pbuffer is single buffered and the context double buffered. This is correct behavior according to the pbuffer spec. Window behavior should be corrected in a subsequent release so that window compatibility is properly tested against contexts. See the section at the end about Impact-specific glxMakeCurrentRead Compatibility. 6.6 _P_b_u_f_f_e_r__p_e_r_f_o_r_m_a_n_c_e The single most important thing you can do to insure good pbuffer performance on impact is to make sure that the windows that your applications are using are not using X visuals with Z bitplanes unless absolutely necessary. There are conditions outlined below under "pbuffer bank calculations" which cause zbuffers to have to swap into host memory when their bank usage conflicts with pbuffers. The simplest way to avoid this is to create all windows using visuals without zbuffers. The most expensive operation with pbuffers is actually glXMakeCurrentReadSGIX. Try to minimize your use of this routine in order to maximize performance. In pursuit of this goal, you should try to minimize the number of contexts you use in your application. 6.7 _P_b_u_f_f_e_r__b_a_n_k__c_a_l_c_u_l_a_t_i_o_n_s In order to calculate how many pbuffers you can have concurrently with your windows, use the following procedure. Determine how many pbuffer banks are available in your system, using the table below called "Pbuffer bank availability". This is the number of pbuffer banks available on your system. Now you need to determine how many banks your application requires. Use the table below called "Pbuffer bank usage" - 4 - to look up how many banks each of the buffers that your application uses requires. Note that this is a global resource, so you must include in your calculations all applications running the on the machine. If another application allocates a pbuffer, then there is one fewer pbuffer bank available for your application. Similarly, if any application uses a Z buffer, there will not be enough pbuffer banks to support a pbuffer at the same time. Pbuffers are capable of sharing the pbuffer banks with Z buffers, and the X server supports swapping the pbuffer bank when necessary so the bitplanes may be used for both purposes at once. This will incur a substantial performance penalty which may be prohibitive for some applications. In other cases where applications are willing to accept pbuffer/zbuffer swapping, you may allow a pbuffer to "share" bitplanes with a zbuffer in your calculations. The one exception to this sharing is that you cannot use glXMakeCurrentReadSGIX with both a window with a zbuffer and a pbuffer that resides in the same bitplanes as that zbuffer. In such a case, glXMakeCurrentReadSGIX will return GL_FALSE and fail. 6.8 _E_x_a_m_p_l_e__p_b_u_f_f_e_r__b_a_n_k__c_a_l_c_u_l_a_t_i_o_n_s Note that "overlap" in the table below refers to zbuffer/pbuffer overlap. Such overlap is not allowed in a single call to glXMakeCurrentReadSGIX. Such overlap may incur swapping performance penalties. 6.8.1 _n_o__o_v_e_r_l_a_p +o 0 banks window +o 1 bank window + z/s buffer +o 1 bank window + 12(L) pbuffer +o 1 bank window + 8888 pbuffer +o 2 banks window + (2) 12(L) pbuffers +o 2 banks window + (2) 8888 pbuffers +o 2 banks window + 8888 pbuffer + z/s buffer +o 3 banks window + (2) 8888 pbuffer + z/s buffer - 5 - +o 2 banks window + 12/12/12 pbuffer + z/s buffer 6.8.2 _w_i_t_h__o_v_e_r_l_a_p +o 0 banks window +o 1 bank window + z/s buffer +o 1 bank window + 12(L) pbuffer +o 1 bank window + 8888 pbuffer +o 2 banks window + (2) 12(L) pbuffers +o 2 banks window + (2) 8888 pbuffers +o 1 banks window + 8888 pbuffer + z/s buffer +o 2 banks window + (2) 8888 pbuffer + z/s buffer +o 2 banks window + 12/12/12 pbuffer + z/s buffer 6.9 _P_b_u_f_f_e_r__b_a_n_k__a_v_a_i_l_a_b_i_l_i_t_y The framebuffer memory available for pbuffers in Max and High Impact systems are organized as follows. Note that on High Impact, the number of banks available for pbuffers depends on the timing table which is loaded when the X Server starts. 6.9.1 _M_a_x__I_m_p_a_c_t +o normal timing tables: 2 pbuffer banks +o 1024x768 timing tables: 4 pbuffer banks +o 1600x1200 timing table: 1 pbuffer bank +o 1600x1200 32db: none 6.9.2 _H_i_g_h__I_m_p_a_c_t__a_n_d__S_o_l_i_d__I_m_p_a_c_t +o normal timing tables: 1 pbuffer bank +o 1024x768 timing tables: 1 pbuffer bank +o 1024x768 pbuf: 2 pbuffer banks - 6 - +o 32db timing tables: none +o 1600x1200 timing table: none 6.10 _P_b_u_f_f_e_r__b_a_n_k__u_s_a_g_e OpenGL pbuffer bank usage: 6.10.1 _C_o_l_o_r__b_u_f_f_e_r_s +o two banks db 8/8/8/8 +o two banks db 12/12/12 +o two banks stereo db (any resolution) +o one bank all other color resolutions 6.10.2 _A_n_c_i_l_l_a_r_y__b_u_f_f_e_r_s +o add one extra bank for visuals with Z and/or stencil N.B.: 12-12-12 color buffers (without depth) are prohibited from being allocated in the bitplanes normally used by the zbuffer (pbuffer bank 0). The zbuffer bank will be allocated last when you are allocating a series of pbuffers, so the simplest workaround is simply to make sure that you allocate any 12-12-12 pbuffers before your other pbuffers. This restriction will manifest itself as glxCreateGLXPbufferSGIX failing due to BadAlloc. 6.11 _I_m_p_a_c_t_-_s_p_e_c_i_f_i_c__g_l_X_M_a_k_e_C_u_r_r_e_n_t_R_e_a_d__C_o_m_p_a_t_i_b_i_l_i_t_y +o 1) Render types must match (color index/rgba). +o 2) Pbuf with depth & window with depth are incompatible. +o 3) Pbufs in bank 0 and window with z are incompatible. (Pbuffers will be put in bank 0 last.) (Pbuffers allocated earlier are not likely to be in bank 0.) +o 4) Color depths of drawables do NOT need to match. +o 5) DB/Stereo do NOT need to match.